• We include busybox in the runtime (AFAIK, npd calls some binaries in the runtime), so binary size increased 134MB -> 145MB
• CVE: from 178 packages, 121 vulnerabilities to 122 packages, 17 vulnerabilities
  (Benchmark image: registry.k8s.io/node-problem-detector/node-problem-detector:v0.8.13)

Any dependency we bump here breaks the compatibility directly.

NAME                 INSTALLED                           FIXED-IN                           TYPE       VULNERABILITY        SEVERITY
k8s.io/apimachinery  v0.0.0-20190816221834-a9f1d8a9c101  0.0.0-20190927203648-9ce6eca90e73  go-module  GHSA-74fp-r6jw-h4mp  High
k8s.io/kubernetes    v1.14.6                                                                go-module  GHSA-74j8-88mm-7496  Medium
k8s.io/kubernetes    v1.14.6                                                                go-module  GHSA-j9wf-vvm6-4r9w  Medium
k8s.io/kubernetes    v1.14.6                                                                go-module  GHSA-vw47-mr44-3jf9  Low
k8s.io/kubernetes    v1.14.6                             1.16.0-beta.1                      go-module  GHSA-jmrx-5g74-6v2f  Medium
k8s.io/kubernetes    v1.14.6                             1.16.11                            go-module  GHSA-wqv3-8cm6-h6wg  High
k8s.io/kubernetes    v1.14.6                             1.18.18                            go-module  GHSA-g42g-737j-qx6j  Medium
k8s.io/kubernetes    v1.14.6                             1.18.19                            go-module  GHSA-qh36-44jv-c8xj  Low
k8s.io/kubernetes    v1.14.6                             1.19.15                            go-module  GHSA-f5f7-6478-qm6p  High
k8s.io/kubernetes    v1.14.6                             1.20.0-alpha.1                     go-module  GHSA-8mjg-8c8g-6h85  Medium
k8s.io/kubernetes    v1.14.6                             1.20.0-alpha.2                     go-module  GHSA-8cfg-vx93-jvxw  Medium
k8s.io/kubernetes    v1.14.6                             1.24.14                            go-module  GHSA-xc8m-28vv-4pjc  Low

Fixes:

Related:

Pre-review Checklist

• IMPORTANT: 'image-request' tag has been applied if this PR is adding any images, including new versions or variants

Quality Requirements for Images PRs

The items in this checklist should all be checked in the PR with exceptions clearly documented.
The general idea is that to the extent possible, the image should be a drop-in replacement to its public counterpart.

• Image is a smaller size than its common public counterpart, or if not, the reason why should be explained:
• Image should be scanned for CVEs and should return 0 or near-0 results. Exceptions should be explained.
• The software in the image should be able to be installed and work as expected
  • The image should start in a cluster
  • The application should be accessible to the user/cluster/etc. as expected
• If there is an open source helm chart provided, the image should be able to be used with the chart. If needed, please add a -compat package to close any gaps with the public helm chart.
• build for x86_64 and aarch64 if possible, document exceptions

For new image PRs only

If you have an apko.yaml file in this PR you need to follow this checklist, otherwise feel free to remove.

• Include tests, sufficient enough that you would trust this image running in production.

• Perform manual tests as needed and document your testing results

  • For builder images (go, python, etc), build a sample app successfully
  • For services images (rabbit, databases, webservers) test basic functionality, upstream install/getting started, port availability, admin access. Document differences from public image.
  • Applications intended for use with a specific cloud provider must be tested on that cloud provider.

• The version included is the latest GA version of the software

• The latest tag points to the newest stable version

• There is a dev tag available that includes a shell and apk tools (by depending on 'wolfi-base')

• The image runs as nonroot and GID/UID are set to 65532 or upstream default

  • Alternatively the username and GID/UID may be a commonly used one from the ecosystem e.g: postgres

• The image contains the ca-certs bundle if needed

• ENTRYPOINT

  • For applications/servers/utilities call main program with no arguments e.g. [redis-server]
  • For base images leave empty
  • For dev variants set to entrypoint script that falls back to system

• CMD:

  • For server applications give arguments to start in daemon mode (may be empty)
  • For utilities/tooling bring up help e.g. –help
  • For base images with a shell, call it e.g. [/bin/sh]

• Add annotations e.g:

annotations:
  "org.opencontainers.image.authors": "Chainguard Team https://www.chainguard.dev/"
  "org.opencontainers.image.url": https://edu.chainguard.dev/chainguard/chainguard-images/reference/busybox/ # use the academy site here
  "org.opencontainers.image.source": https://github.com/chainguard-images/images/tree/main/images/bazel # use github here

• Check if environment variables are needed e.g. to set data locations
• Ensure the image responds to SIGTERM
  • docker kill $(docker run -d --rm cgr.dev/chainguard/nginx)
• Error logs write to stderr and normal logs to stdout. DO NOT write to file.

Documentation Requirements

• Provide a README file, follow the README template to include variants, tags, and usage examples
• Document your testing and results in the PR
• Document any exceptions to the testing and config requirements outlined in this template
• Document where and how the image deviates from popular alternatives (ports, packages, user, entrypoint, versions, etc). Explain why there's a difference and if the user needs to do anything differently when using the image